\chapter{Dependabilidade}
\section{Estudo sobre dependabilidade}

Desenvolver um sistema com alta dependabilidade requer um grau de conhecimento elevado sobre características de faltas. Segundo Laprie~\cite{laprie98}, dependabilidade é a propriedade que define a capacidade dos sistemas computacionais de prestar um serviço que se pode justificadamente confiar e segundo Avizienis et al~\cite{avizienis04}, dependabilidade é uma integração dos conceitos de segurança, confiabilidade, manutenibilidade, usabilidade, confidencialidade e integridade. Pode-se inferir que a dependabilidade é alta quando os conceitos que a compõem possuem uma boa avaliação.

Durante os últimos 50 anos, muitos meios foram desenvolvidos para atingir os vários atributos de dependabilidade e segurança~\cite{avizienis04}. Esses meios podem ser agrupados em quatro principais categorias:

\begin{itemize}
	\item {\bf Prevenção de faltas:} meios para prevenir a ocorrência ou a introdução de faltas.
	\item {\bf Tolerância a faltas:} meios para evitar faltas de serviço na presença de faltas.
	\item {\bf Remoção de faltas:} meios para reduzir o número e a severidade de faltas.
	\item {\bf Previsão de faltas:} meios de estimar o número presente, a incidência futura, e as prováveis consequências das faltas.
\end{itemize}

Prevenção de faltas e tolerância a faltas tem o objetivo de proporcionar a habilidade de entregar um serviço que é confiável e remoção de faltas e previsão de faltas tem o objetivo de alcançar a confiança da habilidade por meio da justificação de que as especificações funcionais e da dependabilidade e segurança são adequadas e que o sistema é susceptível de alcançá-los.

Com relação as fases de um sistema, elas se dividem em duas, uma de desenvolvimento e outra de uso. 

Na {\bf fase de desenvolvimento} o sistema interage com o ambiente de desenvolvimento e as faltas de desenvolvimento devem ser introduzidas no sistema pelo ambiente. O ambiente de desenvolvimento é composto pelos elementos: o mundo físico, os desenvolvedores, as ferramentas de desenvolvimento e as instalações de produção e testes.

A {\bf fase de uso} inicia-se quando o sistema é aceito e ele começa a ser disponibilizado para os usuários. O “uso” consiste na alternância dos períodos de uma correta prestação de serviços, interrupção de serviço (causado por uma falha) e desligamento do serviço (uma parada proposital da prestação do serviço por uma entidade autorizada). A manutenção tem lugar nos três períodos da fase de uso. O ambiente de uso é composto pelos elementos: o mundo físico, administradores, usuários, fornecedores, infraestrutura e intrusos.

A manutenção não inclui somente reparos físicos, como também modificações do sistema que possuem lugar durante a fase de uso. É possível notar que reparo e tolerância a faltas são conceitos relacionados. A diferença entre a tolerância a faltas e manutenção é que a manutenção envolve a participação de um agente externo, por exemplo, um reparador, equipamento de teste, controle remoto de recarga de software. Além disso, a diferença é que reparo é parte de remoção de faltas (durante a fase de uso), e previsão de faltas normalmente considera situações de reparo. De fato, reparo pode ser visto como uma atividade de tolerância a faltas dentro de um sistema maior que inclui o sistema a ser reparado e as pessoas e outros sistemas que executam tais reparos ~\cite{avizienis04}.

Todas as faltas que podem afetar o sistema durante sua vida são classificadas em oito visões básicas, que levam à uma classe de falta elementar (Figura \ref{fig:basic_faults_8}). Caso seja possível todas as combinações das classes elementares de faltas, significa que 256 combinações de classes de faltas diferentes são possíveis. No entanto, 31 combinações diferentes são possíveis (Figura \ref{fig:figura21}).

\begin{figure}[H]
	\begin{center}
 		\includegraphics[width=0.9\textwidth]{imagens/basic_faults_8.jpg}
 		\caption{Classes Elementares de Faltas~\cite{avizienis04}}
 		\label{fig:basic_faults_8}
	\end{center}
\end{figure}

As faltas combinadas da Figura \ref{fig:basic_faults_8} mostram que as classes combinadas de faltas pertencem a três agrupamentos parcialmente sobrepostos:

\begin{itemize}
 \item {\bf Faltas de desenvolvimento:} inclui todas as faltas que ocorrem durante o desenvolvimento;
 \item {\bf Faltas físicas:} inclui todas as faltas que afetam o hardware;
 \item {\bf Faltas de interação:} inclui todas as faltas externas.
\end{itemize}

\begin{figure}
\begin{center}
	\begin{subfigure}[H]{0.9\textwidth}
                \centering
                \includegraphics[width=\textwidth]{imagens/figura21}
                \caption{Representação em Matriz}
                \label{fig:figura21a}
	\end{subfigure}
	\begin{subfigure}[H]{0.9\textwidth}
                \centering
                \includegraphics[width=\textwidth]{imagens/figura21b}
                \caption{Representação em árvore}
                \label{fig:figura21b}
        \end{subfigure}
\caption{ As classes das faltas combinadas~\cite{avizienis04}.}
\label{fig:figura21}
\end{center}
\end{figure}

Em dependabilidade, para que haja um defeito, é necessário haver uma falta, seguida de um erro. Esse erro poderá gerar o defeito. Uma falta pode causar vários erros simultâneos detectáveis e erros latentes, que são erros não detectáveis. Um erro pode causar defeitos no sistema, sendo estes defeitos classificados como indicado na Figura \ref{fig:figura22}.

\begin{figure}[H]
	\begin{center}
		\includegraphics[width=0.6\textwidth]{imagens/figura22}
		\caption{Modos de defeitos~\cite{avizienis04}.}
		\label{fig:figura22}
	\end{center}
\end{figure}

Em relação a tolerância de faltas em um sistema, foi observado por Laprie~\cite{laprie98} que a ocorrência das fontes de defeito em sistemas tradicionais não tolerante a faltas é de 50\%, 25\%, 15\% e 10\% e em tolerante a faltas é de 8\%, 65\%, 7\% e 10\% para hardware, software, comunicação-ambiente, e operações-procedimentos, respectivamente. Uma comparação feita no trabalho de Schroeder e Gibson~\cite{bianca06} cita que os defeitos relacionados a software vão de 20\% à 50\%, a hardware de 10\% à 30\%, a ambiente cerca de 5\%, a rede entre 20\% à 40\%, e humano de 10\% à 15\%, podendo, este último, variar com o autor. Observaram que as principais diferenças de estudos passados, como os de Laprie, com os dados obtidos por eles, foram em relação à baixa percentagem de erro humano e de rede, devido, primeiramente, ao fato de 20\% à 30\% dos defeitos serem desconhecidos e poderem estar presentes tanto em erro humano como de rede e, secundariamente, ao fato de que o ambiente LANL (Los Alamos National 
Laboratory) é caro, possuindo um grande número de sistemas de HPC (high performance computing) divididos em partições de trabalho dependendo do nível de segurança requerida~\cite{lanl2011}, tornando-o um ambiente muito controlado com obrigações e prioridades de segurança nacional, assim mais recursos podem ser colocados em sua infraestrutura que é colocada em ambientes comerciais.

Como observado por Schroeder e Gibson~\cite{schroeder07}, manter um alto nível de confiabilidade e disponibilidade vem se tornando um problema crescente em sites, incluindo sistemas de HPC e provedores de serviços de internet. Uma das principais preocupações se encontra na confiabilidade dos sistemas de armazenamento, que podem causar não só a perda temporária de seriviço, como podem, no pior caso, levar a uma perda permanente de dados. Esses dados são armazenados tanto para produção de informações sobre o sistema quanto para produção de informações produzidas pela coleta dos dados feitas pelo sistema.

Uma das técnicas utilizadas para análise de faltas é a produção de logs com mensagens que descrevam o comportamento do sistema, associando-as, se possível, com o valor de variáveis de contexto. Porém, esta técnica exige um esforço muito grande do ponto de vista de quem está depurando e a quantidade de logs em um sistema real é muito grande~\cite{araujo10} e, embora essa técnica forneça informações valiosas sobre os componentes individuais, este conhecimento localizado não consegue captar as interações de componentes que caracterizam o comportamento geral do sistema e determinar a experiência do usuário~\cite{chen04}. No trabalho de Schroeder e Gibson~\cite{bianca06}, era coletada uma grande quantidade de logs e quando uma falha era detectada, o nó era direcionado ao administrador para classificar a falta e armazená-la em um banco de dados. Os logs foram classificados de forma manual e como eram em grande quantidade, dificultava o trabalho dos administradores.
